Block shutdown until all pending messages are sent (Fixes #27). #28
Conversation
…rg#27). Ideally the task within our "mdns-responder" thread would block until all the futures actually return Poll::Ready but I can't get that to work, hence the explicit extra blocking I have added.
|
Turns out it's really obvious why the task isn't polling to completion when you look again with fresh eyes. Obviously we need to join the thread we created for our runtime to live in. However, I got bored fighting the compiler and since I couldn't see why each |
kingosticks
force-pushed
the
fix/block-until-all-sent
branch
from
204d684 to
911e802
Compare
|
Thanks - it looks like the Arc around the Shutdown in Responder and Service was intended to make sure the thread is kept alive if either the Service or Responder is kept around. Updating the example to (the slightly ugly): let _svc = {
let responder = libmdns::Responder::new().unwrap();
responder.register(
"_http._tcp".to_owned(),
"libmdns Web Server".to_owned(),
80,
&["path=/"],
)
}; // Responder is dropped as we leave this block... so the thread is shutdown immediately.makes the responder immediately stop responding. I might come up with a solution soon-ish, this library needs a good refactor to use async/await tbh and that'd likely change things a lot. |
|
Ahh I see, makes sense. Thank you for that example. Please feel free to close this as you see fit, I enjoyed messing around with this but I found it hard work so I'll leave it in your hands. |
|
To bump this one, the current (pre-PR) behavior causes |
|
Auto-closed as I renamed |
My first attempt didn't include a new sync_channel and I had expected that to be enough to make the Tokio runtime within the "mdns-responder" thread keep polling the futures until they all returned
Poll::Ready(()), after first sending everything (specifically the goodbye messages) sitting in their outgoing queue. But that didn't work. It's as if theblock_oncall didn't actually block and prevent the thread from stopping before we are finished... I would very much like to hear from anyone who could explain why that is happening, I do not have a good grasp of Tokio, let alone Futures, or even Rust...I would not be surprised to learn there's a far nicer way of doing this, but after much frustration this is where I ended up! Feel free to scrap this and implement a nicer fix.